Long Term Evolution (LTE)
Third-generation mobile systems (3G) based on WCDMA radio-access technology are being deployed on a broad scale all around the world. A first step in enhancing or evolving this technology entails introducing High-Speed Downlink Packet Access (HSDPA) and an enhanced uplink, also referred to as High Speed Uplink Packet Access (HSUPA), giving a radio-access technology that is highly competitive. In order to be prepared for further increasing user demands and to be competitive against new radio access technologies 3GPP introduced a new mobile communication system which is called Long Term Evolution (LTE). LTE is designed to meet the carrier needs for high speed data and media transport as well as high capacity voice support to the next decade. The ability to provide high bit rates is a key measure for LTE. The work item (WI) specification on Long-Term Evolution (LTE) called Evolved UMTS Terrestrial Radio Access (UTRA) and UMTS Terrestrial Radio Access Network (UTRAN) is finalized as Release 8 (Rel. 8 LTE). The LTE system represents efficient packet based radio access and radio access networks that provide full IP-based functionalities with low latency and low cost. In LTE, scalable multiple transmission bandwidths are specified such as 1.4, 3.0, 5.0, 10.0, 15.0, and 20.0 MHz, in order to achieve flexible system deployment using a given spectrum. In the downlink, Orthogonal Frequency Division Multiplexing (OFDM) based radio access was adopted because of its inherent immunity to multipath interference (MPI) due to a low symbol rate, the use of a cyclic prefix (CP), and its affinity to different transmission bandwidth arrangements. Single-carrier frequency division multiple access (SC-FDMA) based radio access was adopted in the uplink, since provisioning of wide area coverage was prioritized over improvement in the peak data rate considering the restricted transmission power of the user equipment (UE). Many key packet radio access techniques are employed including multiple-input multiple-output (MIMO) channel transmission techniques, and a highly efficient control signaling structure is achieved in Rel. 8 LTE.
LTE Architecture
The overall architecture is shown in FIG. 1 and a more detailed representation of the E-UTRAN architecture is given in FIG. 2. The E-UTRAN consists of eNBs, providing the E-UTRA user plane (PDCP/RLC/MAC/PHY) and control plane (RRC) protocol terminations towards the UE. The eNB hosts the Physical (PHY), Medium Access Control (MAC), Radio Link Control (RLC), and Packet data Control Protocol (PDCP) layers that include the functionality of user-plane header-compression and encryption. It also offers Radio Resource Control (RRC) functionality corresponding to the control plane. It performs many functions including radio resource management, admission control, scheduling, enforcement of negotiated UL QoS, cell information broadcast, ciphering/deciphering of user and control plane data, and compression/decompression of DL/UL user plane packet headers. The eNBs are interconnected with each other by means of the X2 interface. The eNBs are also connected by means of the S1 interface to the EPC (Evolved Packet Core), more specifically to the MME (Mobility Management Entity) by means of the S1-MME and to the Serving Gateway (S-GW) by means of the S1-U. The S1 interface supports a many-to-many relation between MMEs/Serving Gateways and eNBs. The SGW routes and forwards user data packets, while also acting as the mobility anchor for the user plane during inter-eNB handovers and as the anchor for mobility between LTE and other 3GPP technologies (terminating S4 interface and relaying the traffic between 2G/3G systems and PDN GW). For idle state UEs, the SGW terminates the DL data path and triggers paging when DL data arrives for the UE. It manages and stores UE contexts, e.g. parameters of the IP bearer service, network internal routing information. It also performs replication of the user traffic in case of lawful interception.
The MME is the key control-node for the LTE access-network. It is responsible for idle mode UE tracking and paging procedure including retransmissions. It is involved in the bearer activation/deactivation process and is also responsible for choosing the SGW for a UE at the initial attach and at time of intra-LTE handover involving Core Network (CN) node relocation. It is responsible for authenticating the user (by interacting with the HSS). The Non-Access Stratum (NAS) signaling terminates at the MME and it is also responsible for generation and allocation of temporary identities to UEs. It checks the authorization of the UE to camp on the service provider's Public Land Mobile Network (PLMN) and enforces UE roaming restrictions. The MME is the termination point in the network for ciphering/integrity protection for NAS signaling and handles the security key management. Lawful interception of signaling is also supported by the MME. The MME also provides the control plane function for mobility between LTE and 2G/3G access networks with the S3 interface terminating at the MME from the SGSN. The MME also terminates the S6a interface towards the home HSS for roaming UEs
Component Carrier Structure in LTE
The downlink component carrier of a 3GPP LTE system is subdivided in the time-frequency domain in so-called subframes. In 3GPP LTE each subframe is divided into two downlink slots as shown in FIG. 3, wherein the first downlink slot comprises the control channel region (PDCCH region) within the first OFDM symbols. Each subframe consists of a give number of OFDM symbols in the time domain (12 or 14 OFDM symbols in 3GPP LTE (Release 8)), wherein each OFDM symbol spans over the entire bandwidth of the component carrier. The OFDM symbols thus each consists of a number of modulation symbols transmitted on respective NDLRB*NRBsc subcarriers as also shown in FIG. 4.
Assuming a multi-carrier communication system, e.g. employing OFDM, as for example used in 3GPP Long Term Evolution (LTE), the smallest unit of resources that can be assigned by the scheduler is one “resource block”. A physical resource block (PRB) is defined as NDLsymb consecutive OFDM symbols in the time domain (e.g. 7 OFDM symbols) and NRBsc consecutive subcarriers in the frequency domain as exemplified in FIG. 4 (e.g. 12 subcarriers for a component carrier). In 3GPP LTE (Release 8), a physical resource block thus consists of NDLsymb*NRBsc resource elements, corresponding to one slot in the time domain and 180 kHz in the frequency domain (for further details on the downlink resource grid, see for example 3GPP TS 36.211, “Evolved Universal Terrestrial Radio Access (E-UTRA); Physical Channels and Modulation (Release 8)”, section 6.2, available at http://www.3gpp.org and incorporated herein by reference).
One subframe consists of two slots, so that there are 14 OFDM symbols in a subframe when a so-called “normal” CP (cyclic prefix) is used, and 12 OFDM symbols in a subframe when a so-called “extended” CP is used. For sake of terminology, in the following the time-frequency resources equivalent to the same NRBsc consecutive subcarriers spanning a full subframe is called a “resource block pair”, or equivalent “RB pair” or “PRB pair”.
The term “component carrier” refers to a combination of several resource blocks in the frequency domain. In future releases of LTE, the term “component carrier” is no longer used; instead, the terminology is changed to “cell”, which refers to a combination of downlink and optionally uplink resources. The linking between the carrier frequency of the downlink resources and the carrier frequency of the uplink resources is indicated in the system information transmitted on the downlink resources.
Similar assumptions for the component carrier structure apply to later releases too.
General Overview of the OSI Layer
FIG. 4 provides a brief overview of the OSI model on which the further discussion of the LTE architecture is based.
The Open Systems Interconnection Reference Model (OSI Model or OSI Reference Model) is a layered abstract description for communication and computer network protocol design. The OSI model divides the functions of a system into a series of layers. Each layer has the property that it only uses the functions of the layer below, and only exports functionality to the layer above. A system that implements protocol behavior consisting of a series of these layers is known as a ‘protocol stack’ or ‘stack’. Its main feature is in the junction between layers which dictates the specifications on how one layer interacts with another. This means that a layer written by one manufacturer can operate with a layer from another. For the purposes of the present disclosure, only the first three layers will be described in more detail below.
The physical layer or layer 1's main purpose is the transfer of information (bits) over a specific physical medium (e.g. coaxial cables, twisted pairs, optical fibers, air interface, etc.). It converts or modulates data into signals (or symbols) that are transmitted over a communication channel.
The purpose of the data link layer (or Layer 2) is to shape the information flow in a way compatible with the specific physical layer by breaking up the input data into data frames (Segmentation And Re-assembly (SAR) functions). Furthermore, it may detect and correct potential transmission errors by requesting a retransmission of a lost frame. It typically provides an addressing mechanism and may offer flow control algorithms in order to align the data rate with the receiver capacity. If a shared medium is concurrently used by multiple transmitters and receivers, the data link layer typically offers mechanisms to regulate and control access to the physical medium.
As there are numerous functions offered by the data link layer, the data link layer is often subdivided into sublayers (e.g. RLC and MAC sublayers in UMTS). Typical examples of Layer 2 protocols are PPP/HDLC, ATM, frame relay for fixed line networks and RLC, LLC or MAC for wireless systems. More detailed information on the sublayers PDCP, RLC and MAC of layer 2 is given later.
The network layer or Layer 3 provides the functional and procedural means for transferring variable length packets from a source to a destination via one or more networks while maintaining the quality of service requested by the transport layer. Typically, the network layer's main purposes are inter alia to perform network routing, network fragmentation and congestion control functions. The main examples of network layer protocols are the IP Internet Protocol or X.25.
With respect to Layers 4 to 7 it should be noted that depending on the application and service it is sometimes difficult to attribute an application or service to a specific layer of the OSI model since applications and services operating above Layer 3 often implement a variety of functions that are to be attributed to different layers of the OSI model. Therefore, especially in TCP(UDP)/IP based networks, Layer 4 and above is sometimes combined and forms a so-called “application layer”.
Layer Services and Data Exchange
In the following the terms service data unit (SDU) and protocol data unit (PDU) as used herein are defined in connection with FIG. 5. In order to formally describe in a generic way the exchange of packets between layers in the OSI model, SDU and PDU entities have been introduced. An SDU is a unit of information (data/information block) transmitted from a protocol at layer N+1 that requests a service from a protocol located at layer N via a so-called service access point (SAP). A PDU is a unit of information exchanged between peer processes at the transmitter and at the receiver of the same protocol located at the same layer N.
A PDU is generally formed by a payload part consisting of the processed version of the received SDU(s) preceded by a layer N specific header and optionally terminated by a trailer. Since there is no direct physical connection (except for Layer 1) between these peer processes, a PDU is forwarded to the layer N−1 for processing. Therefore, a layer N PDU is from a layer N−1 point of view an SDU.
LTE Layer 2—User Plane and Control Plane Protocol Stack
The LTE layer 2 user-plane/control-plane protocol stack comprises three sublayers as shown in FIG. 6, PDCP, RLC and MAC. As explained before, at the transmitting side, each layer receives a SDU from a higher layer for which the layer provides a service and outputs a PDU to the layer below. The RLC layer receives packets from the PDCP layer. These packets are called PDCP PDUs from a PDCP point of view and represent RLC SDUs from an RLC point of view. The RLC layer creates packets which are provided to the layer below, i.e. the MAC layer. The packets provided by RLC to the MAC layer are RLC PDUs from an RLC point of view and MAC SDUs from a MAC point of view.
At the receiving side, the process is reversed, with each layer passing SDUs up to the layer above, where they are received as PDUs.
While the physical layer essentially provides a bitpipe, protected by turbo-coding and a cyclic redundancy check (CRC), the link-layer protocols enhance the service to upper layers by increased reliability, security and integrity. In addition, the link layer is responsible for the multi-user medium access and scheduling. One of the main challenges for the LTE link-layer design is to provide the required reliability levels and delays for Internet Protocol (IP) data flows with their wide range of different services and data rates. In particular, the protocol over-head must scale. For example, it is widely assumed that voice over IP (VoIP) flows can tolerate delays on the order of 100 ms and packet losses of up to one percent. On the other hand, it is well-known that TCP file downloads perform better over links with low bandwidth-delay products. Consequently, downloads at very high data rates (e.g., 100 Mb/s) require even lower delays and, in addition, are more sensitive to IP packet losses than VoIP traffic.
Overall, this is achieved by the three sublayers of the LTE link layer that are partly intertwined.
The Packet data Convergence Protocol (PDCP) sublayer is responsible mainly for IP header compression and ciphering. In addition, it supports lossless mobility in case of inter-eNB handovers and provides integrity protection to higher layer-control protocols.
The radio link control (RLC) sublayer comprises mainly ARQ functionality and supports data segmentation and concatenation. The latter two minimize the protocol overhead independent of the data rate.
Finally, the medium access control (MAC) sublayer provides HARQ and is responsible for the functionality that is required for medium access, such as scheduling operation and random access. FIG. 7 exemplary depicts the data flow of an IP packet through the link-layer protocols down to the physical layer. The Figure shows that each protocol sublayer adds its own protocol header to the data units.
Packet Data Convergence Protocol (PDCP)
The PDCP layer processes Radio Resource Control (RRC) messages in the control plane and IP packets in the user plane. Depending on the radio bearer characteristics and the mode of the associated RLC entity (AM, UM, TM), the main functions performed by a PDCP entity of the PDCP layer are:                header compression and decompression (e.g. using Robust Header Compression (ROHC) for user plane data (DRB)        Security functions:        Ciphering and deciphering for user plane and control plane data (for SRB and DRB)        Integrity protection and verification for control plane data (for SRB)        Maintenance of PDCP sequence numbers for SRB and DRB        Handover support functions:        In-sequence delivery and reordering of PDUs for the layer above at handover for AM DRB;        Lossless handover for user plane data mapped on RLC Acknowledged Mode (AM); including Status Reporting for AM DRBs and duplicate elimination of lower layers SDUs for AM DRB        Discard for user plane data due to timeout (for SRB and DRB).        
The PDCP layer manages data streams in the user plane, as well as in the control plane, only for the radio bearers using either a Dedicated Control Channel (DCCH) or a Dedicated Transport Channel (DTCH). The architecture of the PDCP layer differs for user plane data and control plane data. Two different types of PDCP PDUs are defined in LTE: PDCP data PDUs and PDCP Control PDUs. PDCP data PDUs are used for both control and user plane data. PDCP Control PDUs are only used to transport the feedback information for header compression, and for PDCP status reports which are used in case of handover and hence are only used within the user plane.
Buffer Status Reporting
The Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data available for transmission in the UL buffers of the UE. RRC controls BSR reporting by configuring the two timers periodicBSR-Timer and retxBSR-Timer and by, for each logical channel, optionally signalling logicalChannelGroup which allocates the logical channel to an LCG.
For the Buffer Status reporting procedure, the UE shall consider all radio bearers which are not suspended and may consider radio bearers which are suspended.
A Buffer Status Report (BSR) shall be triggered if any of the following events occur:                UL data, for a logical channel which belongs to a LCG, becomes available for transmission in the RLC entity or in the PDCP entity (the definition of what data shall be considered as available for transmission is specified in section 5.4 of document TS36.321-a.4.0), and either the data belongs to a logical channel with higher priority than the priorities of the logical channels which belong to any LCG and for which data is already available for transmission, or there is no data available for transmission for any of the logical channels which belong to a LCG, in which case the BSR is referred below to as “Regular BSR”;        UL resources are allocated and the number of padding bits is equal to or larger than the size of the Buffer Status Report MAC control element plus its subheader, in which case the BSR is referred below to as “Padding BSR”;        retxBSR-Timer expires and the UE has data available for transmission for any of the logical channels which belong to a LCG, in which case the BSR is referred below to as “Regular BSR”;        periodicBSR-Timer expires, in which case the BSR is referred below to as “Periodic BSR”.        
For Regular and Periodic BSR:                if more than one LCG has data available for transmission in the TTI where the BSR is transmitted: report Long BSR;        else report Short BSR.        
For Padding BSR:                if the number of padding bits is equal to or larger than the size of the Short BSR plus its subheader but smaller than the size of the Long BSR plus its subheader:        if more than one LCG has data available for transmission in the TTI where the BSR is transmitted: report Truncated BSR of the LCG with the highest priority logical channel with data available for transmission;        else report Short BSR.        else if the number of padding bits is equal to or larger than the size of the Long BSR plus its subheader: report Long BSR.        
If the buffer Status reporting procedure determines that at least one BSR has been triggered and not cancelled:                if the UE has UL resources allocated for new transmission for this TTI:        instruct the Multiplexing and Assembly procedure to generate the BSR MAC control element(s);        start or restart periodicBSR-Timer except when all the generated BSRs are Truncated BSRs;        start or restart retxBSR-Timer.        else if a Regular BSR has been triggered:        if an uplink grant is not configured or the Regular BSR was not triggered due to data becoming available for transmission for a logical channel for which logical channel SR masking (logicalChannelSR-Mask) is setup by upper layers:        a Scheduling Request shall be triggered.        
A MAC PDU shall contain at most one MAC BSR control element, even when multiple events trigger a BSR by the time a BSR can be transmitted in which case the Regular BSR and the Periodic BSR shall have precedence over the padding BSR.
The UE shall restart retxBSR-Timer upon indication of a grant for transmission of new data on any UL-SCH.
All triggered BSRs shall be cancelled in case the UL grant(s) in this subframe can accommodate all pending data available for transmission but is not sufficient to additionally accommodate the BSR MAC control element plus its subheader. All triggered BSRs shall be cancelled when a BSR is included in a MAC PDU for transmission.
The UE shall transmit at most one Regular/Periodic BSR in a TTI. If the UE is requested to transmit multiple MAC PDUs in a TTI, it may include a padding BSR in any of the MAC PDUs which do not contain a Regular/Periodic BSR.
All BSRs transmitted in a TTI always reflect the buffer status after all MAC PDUs have been built for this TTI. Each LCG shall report at the most one buffer status value per TTI and this value shall be reported in all BSRs reporting buffer status for this LCG.
NOTE: A Padding BSR is not allowed to cancel a triggered Regular/Periodic BSR. A Padding BSR is triggered for a specific MAC PDU only and the trigger is cancelled when this MAC PDU has been built.
Logical Channel Prioritization
The Logical Channel Prioritization (LCP) procedure is applied when a new transmission is performed.
RRC controls the scheduling of uplink data by signalling for each logical channel:                priority where an increasing priority value indicates a lower priority level,        prioritisedBitRate which sets the Prioritized Bit Rate (PBR),        bucketSizeDuration which sets the Bucket Size Duration (BSD).        
The UE shall maintain a variable Bj for each logical channel j. Bj shall be initialized to zero when the related logical channel is established, and incremented by the product PBR×TTI duration for each TTI, where PBR is Prioritized Bit Rate of logical channel j. However, the value of Bj can never exceed the bucket size and if the value of Bj is larger than the bucket size of logical channel j, it shall be set to the bucket size. The bucket size of a logical channel is equal to PBR×BSD, where PBR and BSD are configured by upper layers.
The UE shall perform the following Logical Channel Prioritization procedure when a new transmission is performed:                The UE shall allocate resources to the logical channels in the following steps:        Step 1: All the logical channels with Bj>0 are allocated resources in a decreasing priority order. If the PBR of a radio bearer is set to “infinity”, the UE shall allocate resources for all the data that is available for transmission on the radio bearer before meeting the PBR of the lower priority radio bearer(s);        Step 2: the UE shall decrement Bj by the total size of MAC SDUs served to logical channel j in Step 1        
NOTE: The value of Bj can be negative.                Step 3: if any resources remain, all the logical channels are served in a strict decreasing priority order (regardless of the value of Bj) until either the data for that logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority should be served equally.        The UE shall also follow the rules below during the scheduling procedures above:        The UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources;        if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill the grant as much as possible;        UE should maximise the transmission of data.        
The UE shall not transmit data for a logical channel corresponding to a radio bearer that is suspended (the conditions for when a radio bearer is considered suspended are defined in TS 36.331).
For the Logical Channel Prioritization procedure, the UE shall take into account the following relative priority in decreasing order:                MAC control element for C-RNTI or data from UL-CCCH;        MAC control element for BSR, with exception of BSR included for padding;        MAC control element for PHR or Extended PHR;        data from any Logical Channel, except data from UL-CCCH;        MAC control element for BSR included for padding.        
When the UE is requested to transmit multiple MAC PDUs in one TTI, steps 1 to 3 and the associated rules may be applied either to each grant independently or to the sum of the capacities of the grants. Also the order in which the grants are processed is left up to UE implementation. It is up to the UE implementation to decide in which MAC PDU a MAC control element is included when UE is requested to transmit multiple MAC PDUs in one TTI.
Further Advancements for LTE (LTE-A and 3GPP Rel. 12)
The frequency spectrum for IMT-Advanced was decided at the World Radio communication Conference 2007 (WRC-07). Although the overall frequency spectrum for IMT-Advanced was decided, the actual available frequency bandwidth is different according to each region or country. Following the decision on the available frequency spectrum outline, however, standardization of a radio interface started in the 3rd Generation Partnership Project (3GPP). At the 3GPP TSG RAN #39 meeting, the study item description on “Further Advancements for E-UTRA (LTE-Advanced)” was approved in the 3GPP. The study item covers technology components to be considered for the evolution of E-UTRA, e.g. to fulfill the requirements on IMT-Advanced.
Further, in Rel. 12 one major technology components which are currently under consideration for LTE is described in the following.
Small Cells
Explosive demands for mobile data are driving changes in how mobile operators will need to respond to the challenging requirements of higher capacity and improved quality of user experience (QoE). Currently, fourth generation wireless access systems using Long Term Evolution (LTE) are being deployed by many operators worldwide in order to offer faster access with lower latency and more efficiency than 3G/3.5G. Nevertheless, the anticipated future traffic growth is so tremendous that there is a vastly increased need for further network densification to handle the capacity requirements, particularly in high traffic areas (hot spot areas) that generate the highest volume of traffic. Network densification—increasing the number of network nodes, and thereby bringing them physically closer to the user terminals—is a key to improving traffic capacity and extending the achievable user-data rates of a wireless communication system. In addition to straightforward densification of a macro deployment, network densification can be achieved by the deployment of complementary low-power nodes respectively small cells under the coverage of an existing macro-node layer. In such a heterogeneous deployment, the low-power nodes provide very high traffic capacity and very high user throughput locally, for example in indoor and outdoor hotspot positions.
Meanwhile, the macro layer ensures service availability and QoE over the entire coverage area. In other words, the layer containing the low-power nodes can also be referred to as providing local-area access, in contrast to the wide-area-covering macro layer. The installation of low-power nodes respectively small cells as well as heterogeneous deployments has been possible since the first release of LTE. In this regard, a number of solutions have been specified in recent releases of LTE (i.e., Release 10/11). More specifically, these releases introduced additional tools to handle inter-layer interference in heterogeneous deployments. In order to further optimize performance and provide cost/energy-efficient operation, small cells require further enhancements and in many cases need to interact with or complement existing macrocells. Such solutions will be investigated during the further evolution of LTE-Release 12 and beyond. In particular further enhancements related to low-power nodes and heterogeneous deployments will be considered under the umbrella of the new Rel-12 study item (SI) “Study on Small Cell Enhancements for E-UTRA and E-UTRAN”. Some of these activities will focus on achieving an even higher degree of interworking between the macro and low-power layers, including different forms of macro assistance to the low-power layer and dual-layer connectivity. Dual connectivity implies that the device has simultaneous connections to both macro and low-power layers.
Deployment Scenarios within Small Cell Enhancement SI
This section describes the deployment scenarios assumed in the study item (SI) on small cell enhancements. In the following scenarios, the backhaul technologies categorised as non-ideal backhaul in TR 36.932 are assumed. Fibre access which can be used to deploy Remote Radio Heads (RRHs) is not assumed in this study. HeNBs are not precluded, but not distinguished from Pico eNBs in terms of deployment scenarios and challenges even though the transmission power of HeNBs is lower than that of Pico eNBs. Following 3 scenarios, illustrated in FIG. 8, are considered:
Scenario #1. Scenario #1 is the deployment scenario where macro and small cells on the same carrier frequency (intra-frequency) are connected via a non-ideal backhaul.
Scenario #2. Scenario #2 is the deployment scenario where macro and small cells on different carrier frequencies (inter-frequency) are connected via a non-ideal backhaul. There are essentially two flavours of scenario #2, which is here referred to as Scenario 2a and Scenario 2b, the difference being that in scenario 2b an indoor small cell deployment is considered.
Scenario #3. Scenario #3 is the deployment scenario where only small cells on one or more carrier frequencies are connected via a non-ideal backhaul.
Depending on the deployment scenario, different challenges/problems exist which need to be further investigated. During the study item phase such challenges have been identified for the corresponding deployment scenario and captured in TS36.842. More details on those challenges/problems can be found there.
In order to resolve the identified challenges which are described in section 5 of TS36.842, the following design goals are taken into account for this study in addition to the requirements specified in TR 36.932.
In terms of mobility robustness: for UEs in RRC_CONNECTED, Mobility performance achieved by small cell deployments should be comparable with that of a macro only network.
In terms of increased signalling load due to frequent handover: any new solutions should not result in excessive increase of signalling load towards the CN. However, additional signalling and user plane traffic load caused by small cell enhancements should also be taken into account.
In terms of improving per-user throughput and system capacity: utilising radio resources across macro and small cells in order to achieve per-user throughput and system capacity similar to ideal backhaul deployments while taking into account QoS requirements should be targeted.
Logical Channel Prioritization (LCP)
The finite radio resource should be allocated and used carefully among the UEs and radio bearers. In the downlink, the eNB is the focal point through which all downlink data flows before being transmitted over the radio interface to each UE. Thus, the eNB can make consistent decisions about which downlink data should be transmitted first. However, in the uplink, each UE makes an individual decision based only on the data in its own buffers and the allocated radio resource. To ensure that each UE makes the best and most consistent decisions in terms of using the allocated radio resource, the Logical Channel Prioritization (LCP) procedure is introduced. The LCP procedure is used for MAC PDU construction by deciding the amount of data from each logical channel and the type of MAC Control Element that should be included in the MAC PDU. By using the LCP procedure, the UE can satisfy the QoS of each radio bearer in the best and most predictable way.
In constructing a MAC PDU with data from multiple logical channels, the simplest and most intuitive method is the absolute priority-based method, where the MAC PDU space is allocated to logical channels in decreasing order of logical channel priority. This is, data from the highest priority logical channel are served first in the MAC PDU, followed by data from the next highest priority logical channel, continuing until the MAC PDU space runs out. Although the absolute priority-based method is quite simple in terms of UE implementation, it sometimes leads to starvation of data from low-priority logical channels. Starvation means that the data from the low-priority logical channels cannot be transmitted because the data from high-priority logical channels take up all the MAC PDU space.
In LTE, a Prioritized Bit Rate (PBR) is defined for each logical channel, in order to transmit data in order of importance but also to avoid starvation of data with lower priority. The PBR is the minimum data rate guaranteed for the logical channel. Even if the logical channel has low priority, at least a small amount of MAC PDU space is allocated to guarantee the PBR. Thus, the starvation problem can be avoided by using the PBR.
Constructing a MAC PDU with PBR consists of two rounds. In the first round, each logical channel is served in decreasing order of logical channel priority, but the amount of data from each logical channel included in the MAC PDU is initially limited to the amount corresponding to the configured PBR value of the logical channel. After all logical channels have been served up to their PBR values, if there is room left in the MAC PDU, the second round is performed. In the second round, each logical channel is served again in decreasing order of priority. The major difference for the second round compared to the first round is that each logical channel of lower priority can be allocated with MAC PDU space only if all logical channels of higher priority have no more data to transmit.
A MAC PDU may include not only the MAC SDUs from each configured logical channel but also the MAC CE. Except for a Padding BSR, the MAC CE has a higher priority than a MAC SDU from the logical channels because it controls the operation of the MAC layer. Thus, when a MAC PDU is composed, the MAC CE, if it exists, is the first to be included and the remaining space is used for MAC SDUs from the logical channels. Then, if additional space is left and it is large enough to include a BSR, a Padding BSR is triggered and included in the MAC PDU.
The table below shows the priority order considered when generating a MAC PDU. Among the several types of MAC CE and the data from the logical channels, the C-RNTI MAC CE and data from the UL-CCCH have the highest priority. The C-RNTI MAC CE and data from the UL-CCCH are never included in the same MAC PDU. Unlike data from other logical channels, data from the UL-CCCH have higher priority than other MAC CEs. Because the UL-CCCH transports an RRC message using SRB0, UL-CCCH data must have higher priority than other data. Typically, data from the UL-CCCH are transported during the RA procedure and the size of a MAC PDU from the UL-CCCH is limited. The C-RNTI MAC CE is used during the RA procedure by a UE whose existence is known by the eNB. Since the RA procedure is subject to collision, it is important to have a means by which the eNB can identify each UE. Thus, the UE is required to include its C-RNTI as its identity as early as possible during the RA procedure.
TABLE 1PriorityHighestMAC CE for C-RNTI or data from UL-CCCHMAC CE for BSR, with the exception of BSRincluded for paddingMAC CE for PHRdata from any logical channel, except datafrom UL-CCCHLowestMAC CE for padding BSR
Priority of MAC CEs and Data from Logical Channels
The following illustrates an example of how LTE MAC multiplexing is performed. In this example, the following are assumed:                there are three channels: channel 1 is of the highest priority, channel 2 is of middle priority, and channel 3 is of the lowest priority;        channel 1, channel 2, and channel 3 have been assigned PBR values.        
In the first round, each channel is served up to the data amount equivalent to the PBR according to the order of priority. In this first round, a channel without any configured PBR value is not served. In addition, if the amount of data available for the channel is less than the configured value of the PBR, the channel is served up to the data amount that is available in the buffer. Thus, each channel is allocated space in the MAC PDU up to its configured value of PBR.
In the second round, a logical channel is served only when the following three conditions are met:                after the logical channels of higher priority than the concerned logical channel have been served;        there is space remaining in the MAC PDU;        there is data available in the channel's buffer.        
Accordingly, if there is remaining space in the PDU, channel 1 is served first. Because the remaining data in the buffer for channel 1 are larger than the remaining space in the MAC PDU, all the remaining space in the MAC PDU is allocated to channel 1. Because there is no more space, channels 2 and 3 are not served in the second round.
The description above is the general principle and is not enforced every time a new MAC PDU is composed. Each MAC SDU corresponds to one RLC PDU and one RLC PDU includes at least 1 byte of RLC PDU header. For each MAC SDU, there exists a corresponding at least 1 byte MAC subheader. Thus, whenever a small amount of data from one logical channel is included in a MAC PDU, it will incur at least 2 bytes of header overhead. If the above multiplexing principle was applied in every MAC PDU, the overall overhead caused by the MAC subheader and the RLC PDU header of every logical channel in a MAC PDU would be huge. Thus, rather than applying the above PBR requirements for every subframe, it is better to meet the PBR requirements for a long time period. To reduce the overhead and to prevent too much segmentation, the token-bucket model with PBR is applied.
In the token-bucket model, each logical channel is associated with two parameters: bucketSizeDuration and prioritizedBitRate. In this model, it is assumed that each logical channel is given a right to transmit a prioritizedBitRate amount of data in every subframe. If a certain logical channel has not fully used the right to transmit its prioritizedBitRate amount of data in a certain subframe, the remaining right can be used in another subframe. The right to transmit can be accumulated up to a (prioritizedBitRate×bucketSizeDuration) amount of data. When some data for the logical channel are included in a MAC PDU, the right to transmit is decreased by the amount of data included in the MAC PDU. To prevent a certain logical channel from accumulating too much right to transmit, the parameter bucketSizeDuration sets the limit up to which a logical channel can accumulate the right to transmit. Through this token-bucket model, the UE can meet the PBR principle on average for a longer time period, not per subframe.
In the following, an example of logical channel prioritization is provided. Here, for the given logical channel, it was assumed that bucketSizeDuration was 4 ms (subframes) and prioritizedBitRate was 1 Kb/ms. Thus, the logical channel cannot accumulate more than 4 Kb worth of right to transmit. In other words, even if data from the logical channel have not been transmitted for a long time, the maximum number of bits that the logical channel can transmit is 4 Kb. In the example, the logical channel has not transmitted any data for the 1st subframe to the 5th subframe. But, because of the limited size of the token bucket, the maximum token accumulated by the logical channel at the 5th subframe is 4 Kb. In the 6th subframe, 3 Kb of data from the logical channel have been transmitted. Because 1 Kb worth of token is accumulated at the 7th subframe, the total accumulated token for the logical channel at the end of the 7th subframe is 2 Kb. Thus, even if the logical channel has not transmitted any data, it can make a lot of transmissions at a later time thanks to the accumulated token, but no more than the maximum token.
Dual Connectivity
One promising solution which is currently under discussion in 3GPP RAN working groups is the so-called “dual connectivity” concept. The term “dual connectivity” is used to refer to an operation where a given UE consumes radio resources provided by at least two different network nodes connected with non-ideal backhaul. Essentially UE is connected with both macro cell (macro eNB) and small cell (secondary eNB). Furthermore, each eNB involved in dual connectivity for a UE may assume different roles. Those roles do not necessarily depend on the eNB's power class and can vary among UEs.
Since the study Item is currently at a very early stage, details on the dual connectivity are not decided yet. For example the architecture has not been agreed on yet. Therefore many issues/details, e.g. protocol enhancements, are still open currently. FIG. 9 shows some exemplary architecture for dual connectivity. It should be only understood as one potential option. However the present disclosure is not limited to this specific network/protocol architecture but can be applied generally. Following assumptions on the architecture are made here:                Per bearer level decision where to serve each packet, C/U plane split        As an example UE RRC signalling and high QoS data such as VoLTE can be served by the Macro cell, while best effort data is offloaded to the small cell.        No coupling between bearers, so no common PDCP or RLC required between the Macro cell and small cell        Looser coordination between RAN nodes        SeNB has no connection to S-GW, i.e. packets are forwarded by MeNB        Small Cell is transparent to CN.        
Regarding the last two bullet points, it should be noted that it's also possible that SeNB is connected directly with the S-GW, i.e. S1-U is between S-GW and SeNB. Essentially there are three different options with respect to the bearer mapping/splitting:                option 1: S1-U also terminates in SeNB;        option 2: S1-U terminates in MeNB, no bearer split in RAN;        option 3: S1-U terminates in MeNB, bearer split in RAN.        
FIG. 10 depicts those three options taking the downlink direction for the U-plane data as an example. Option 2 is assumed throughout the description and also shown in the Figure.
A common problem of any wireless communication system is that resources are limited and it is not possible to allocate and use all the resources all the time since there is more than one potential seeker of these resources.
This requirement gets complicated since the allocation and use of the limited resources has to be done in view of what (resource) is minimally required to serve the agreed Quality of Service (QoS) of a bearer of each UE and also in view of that different UEs might be experiencing different radio channels and therefore would need different amount of resources to fulfil even the similar need. The decision of resource allocation is done for every Transmission Time Interval (TTI) which, for LTE, is 1 ms. Thus, every 1 ms, the network needs to decide how much DL resource it allocates towards each of the UEs for which there is some data to be sent to it. Similarly, every 1 ms, the network needs to decide how much UL resource it allocates towards each of the UEs which have information to transmit.
The Downlink (DL) is however different from the Uplink (UL). In DL, the eNB has the complete view of the requirements of all the UEs and their bearer(s). Namely, how much data is to be transmitted to each UE for each of their bearers, what is the radio condition (and therefore which resources are good/bad), QoS etc. In UL however, the network does not know how much data the UE has send on each of its UL bearers. So, it cannot allocate a precise amount of resources for each of the UL bearer of this UE.
One possible solution could be to allocate “sufficient” amount of resources to the UE such that all the UL bearers will be satisfied at least ‘statistically’. However, since the resources are limited, this would very often mean wasting such resources and then some other UEs/bearers will starve. For this reason the UE sends the Buffer Status Report (BSR) from time to time, when certain conditions as specified in chapter 5.4.5 in 3GPP TS 36.321-a40 are met, so that the network has some idea about UE's UL transmission requirements.
Another challenge is that the network has to ensure that a UE implementation does not completely use the provided grant arbitrarily which might make the QoS fulfillment of the bearer(s) difficult. For this purpose certain rules are defined on how the UE shall use the grant across its bearers. This is called Logical Channel Prioritization (LCP) since this is mainly about maintaining some priority between different Logical Channels, which realize the radio bearer(s). Both Buffer Status Reporting and Logical Channel Prioritization are the functions of the MAC sub-layer of LTE Protocol Stack.
In LTE Rel. 8/9, for example, there was only one MAC entity per UE that runs the LCP to allocate grant(s) across all bearer(s) i.e. inform the resulting grant to each of the RLC entity. Even when Carrier Aggregation was introduced in LTE and as a result there were grants received from more than one cell at a time, the single MAC entity was responsible for running LCP and allocated an applicable grant to each RLC entity. This is shown in the diagram of FIG. 11.
With the introduction of Small Cell Enhancements, in one of the possible architecture option, it is possible that physical resources are allocated by more than one Cell to a corresponding MAC entity. In other words, there can be as many MAC entities in the UE as the number of participating cell(s) in the UL. This is not a problem from LCP/BSR reporting point of view since these MAC schedulers can run their own LCP, or report the BSR, and inform the resulting grant to each of their corresponding RLC entities, such as illustrated in FIG. 12.
This is, for instance, the situation in architecture option 2 e.g. 2C which is shown in FIG. 13. In architecture option 2C, the air-interface transmission of a particular bearer is completely via a particular cell; in the diagram of FIG. 13, the left bearer transmission is via MeNB physical resources, and the right bearer transmission is via the SeNB physical resources. The corresponding UE side picture of the Protocol Stack is shown in FIG. 14.
A problem arises in architecture option 3 e.g. 3C which is shown in FIGS. 15 and 16. In particular, in option 3C, the MACs in Cell 1 and 2 do not know how much grant they should allocate for the shared (dashed) bearer since there is no defined rule so far. Therefore, as per today, if these MAC Schedulers strictly run the LCP, then they may end up over-allocating a grant (for instance, each allocating grant to the radio bearer equals to ‘prioritisedBitRate’) to the dashed bearer which now would receive grants twice. On the other hand, it defeats the fundamental purpose of Small Cell Enhancements since the network may want to allocate maximum data to be transmitted via Cell 2 since this is the cell that is used for offloading gain.
Similarly, it is not clear how the Buffer Status will be reported for the data available for transmission corresponding to the dashed bearer. The buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data available for transmission in the UL buffers of the UE. The amount of data available for transmission is the sum of data available for transmission in PDCP and data available for transmission in RLC entity (the details of which are publicly available in 3GPP documents TS 36.322 and 36.323). Further, since (as shown in FIG. 16) the PDCP is a common entity, the Individual RLC entities of the split-dashed-bearer (i.e. RLC of MeNB and RLC of SeNB) derive their SDUs from. Therefore, following the present specification the data available for transmission may double-count the same PDCP SDUs and PDCP PDUs not yet submitted to RLC, one for each MAC entity or cell.
Thus, a configuration in which the UE can communicate with at least two cells while avoiding at least some of the drawbacks illustrated above is preferred.